-
Notifications
You must be signed in to change notification settings - Fork 5
Add a php cs file #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f8efecc
to
3337ac7
Compare
i agree we should have a common code style and find your proposal fine.
i would be happy to stick with the symfony CS and not create exceptions
for whitespace (more to avoid discussion than because of a strong opinion)
+1 for the short array syntax (its what we do already) and the ordered
`use` statements.
what about using the styleci service? the upshot is that this can be
integrated into the pull requests here on github, and their service can
even provide a patch / do a pull request against the branch with the cs
fixes that can be done automatically.
|
+1 from me for both the workflow and the proposal. I was also thinking about styleci, but I am not as impressed now as I was when I found it. What can Style CI do that Scrutinizer doesn't? Also, it seems creating CIs is the hype nowadays. That said, if you think it worth and gives us something more than Scrutinizer, then I would happily set it up. For example I am not sure if Scrutinizer breaks the build or automatically opens a PR. |
styleci is convenient because we would not need to change the travis
build at all, its a completely separate integration and only about cs.
scrutinizer is about coverage and such afaik, less about cs.
|
Ok, convinced me. |
Sorry @dbu i have remove those rules / proposal and also the symfony one, as i don't want to introduce new rules here (2 different purposes) and just want to agree on a operation workflow for the moment. (I will add these in another issue) |
Cool, let's go ahead then. |
Hello ! |
I think it is better kept out of the composer dependencies. |
Do you plan to add the php-cs-fixer dependency to composer or do you
think it's better to require a global installation on developer computer ?
the idea is to commit it in each of the repositories. there would even
be a script that we could adapt to sync the files that must be the same
into all our repos:
https://github.com/dantleech/cmf-utils/blob/master/scripts/sync_styleci
|
Proposal for a cs file see #1 and #2
We all have our habits, way of doing thing, etc... IMO having a common style for code is necessary, however choice of rules should not take forever. Then i want to propose the following workflow for choosing coding rules :
(A contributor in this case is someone who belongs to the organisation)
This is mainly to avoid useless debate for something which is highly subjective.
This cs file include all psr1 and psr2 rules as the base coding style.
If workflow is agreed by everyone, i will propose some other rules.